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Selection of the Ground Segment for the 
Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) 


ABSTRACT. Nexus was a technology demonstrator project that was designed to bridge from the Hubble Space 
Telescope (HST) to its successor, the Next Generation Space Telescope (NGST). This paper focuses on the process 
used in designing the ground segment for Nexus and the lessons learned in its development. Ground station cost 
drivers were, (1) Contact time, (2) Cost of transporting data between the ground stations and control center, and (3) 
Cost savings via ground automation. We found that reducing the communication requirement in just the first 100 
days could have reduced the total ground station cost by 40%. Contact time cost dwarfed the cost trade between 
automation development and off-shift operations personnel. Real-time Telemetry and Control (T&C) system 
analysis was divided into (1) Potential reuse of the Nexus real-time T&C system for NGST, (2) Feasibility of using 
a “Finite State-Based Modeling” product, and (3) Selecting a Commercial Off the Shelf (COTS) versus Government 
Off The Shelf (GOTS) products. We found that each of the products evaluated in detail (AS 1ST, EPOCH 2000, and 
1TOS) could adequately support basic mission requirements. Lessons learned were, (1) Include operations at the 
beginning of the mission, and (2) Develop an operations concept as soon as possible. 
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L Overview: Nexus and NGST 


The Next Generation Space Telescope (NGST) is a large aperture space telescope designated to succeed the Hubble 
Space Telescope (HST). NGST will continue the HST tradition of advancing breakthroughs in our understanding of 
the origins of the earliest stars, galaxies, and very elements that are the foundations of Life. We expect the costs for 
NGST to be reduced substantially from those for HST since NGST will not require Shuttle Mission servicing (it will 
maintain an orbit around L2, the second Lagrange point). Our goal for the NGST ground segment is to reduce the 
cost to between 50% and 75% compared to HST. 

A technology demonstrator project called Nexus was planned for 2005, and was to be a smaller scale telescope than 
NGST, designed to test telescope deployment and optical stability, the Wave Front Sensing and Control process, and 
sunshield thermal performance (see Figure 1). Goddard Space Flight Center (GSFC) and the Space Telescope 
Science Institute (STScI) were jointly developing the Nexus ground system. Due to a re-scope of NGST, Nexus was 
cancelled in December 2000. Many of the concepts and analyses from the Nexus effort are directly applicable to 
NGST. We are currently engaged in evaluation and recommendation of a real-time Telemetry and Command 
(T&C) system for the NGST ground system. This paper focuses on the process we used to select a real-time system 
for Nexus and the lessons learned in developing the Nexus ground system. 
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Nexus is the Logical Step Between Technology Developments... 
•AMSD Cryo Mirrors 
•WFS&C 


•Deployment 
•Sunshield 
•Detectors 
•Industrial IR&D 

..Government and Industry System Studies 

•Designs 

•Metrology 

•Integration 

•Operations 

..Management and Process... 

•Cost 

•Schedule 

•Teaming 

...and the Flight of NGST 




NASA concepts for 
Nexus and NGST 
shown tn same scale 


Figure 1. Nexus Ground Technology and Spacecraft Components Link to NGST 


2. Ground Station Costs 


NASA decided to move away from owning ground stations and toward using commercial centers. NASA did this 
hoping that commercial carriers would reduce the cost of ground stations. Overall, since NASA is currently not 
supplying the space-to-ground link infrastructure, it is no longer a low cost item for missions. NASA should 
consider supplying the space-to-ground link infrastructure to its own and other United States Government missions 
at no cost. It is our finding that the objectives of low cost missions that include ground segments cannot be met 
without this support. 

The ground station costs can be divided into three segments: 

• Contact time and associated costs 

• Cost of transporting data between the ground stations and control center 

• Cost savings via ground automation 
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2.1 Contact Time and Associated Costs 

In determining ground system costs driven by an initial operations concept, it came as a surprise to us that ground 
stations budgets dominated the concept, and even impacted spacecraft requirements. The operations contact 
scenarios (see Figure 2.) were the primary cost driver for the entire ground system. The large cost of the ground 
stations exceeded the combined cost of the real-time ground systems and support personnel. This was largely driven 
by requests for ground station support time that did not reduce risk but allowed personnel to observe spacecraft 
activities in real-time. This push was toward lower risk in spite of the low mission cost requirements. The Nexus 
Flight Software, typical of most spacecraft software, was designed to put the spacecraft in “safe” condition when an 
anomaly occurs. Real-time links maintained during critical activities allowed for quicker recovery from anomalies, 
but in almost all cases did not prevent the need for recovery. 

Ground stations support was narrowed to two organizations: 

• Deep Space Network (DSN-CSOC) 26-meter antenna 

• Universal Space Network (USN) 13-meter antenna 

Early in the Nexus design development, S-band forward transmissions to a low-gain, omni spacecraft antenna were 
found to be unsupportable from a 13-meter ground antenna. A larger, high-gain antenna was included on Nexus to 
enable coverage of the S-band forward RF link during normal operations. The S-band forward to the low-gain 
omni antenna was still needed due to high-gain antenna pointing uncertainty during contingency operations; hence, 
the larger DSN-CSOC antenna was then required for contingencies. The costs for more powerful S-band 
transponders, revised energy budgets, and other spacecraft design considerations limited the amount of cost savings 
that could be achieved on the ground. To allow for smaller antennas, the ground costs also placed data rate 
limitations on the payload. 

2.1.1 Ground Stations: Commercial versus Government 

DSN-CSOC and USN were evaluated for Nexus. Other options and commercial providers were initially considered, 
but were discounted due to limited availability, limited resources, or excessive cost. DSN-CSOC costs were higher 
than the commercial network in all comparison cases. This can be attributed to the larger antennas used by DSN- 
CSOC, and the large number of users requesting these antenna services. While Nexus had only a contingency 
requirement for these large antennas, options for smaller antennas at a lower cost did not exist. The DSN-CSOC 
cost over the Nexus one-year mission life was 33% higher than the USN cost. USN was able to keep costs down by 
providing a smaller antenna and having the Nexus Project depend on DSN-CSOC for contingency operations. 

The overall cost for both systems could have been dramatically lowered by reducing the initial “24 hours/day, 7 
days/week” communications requirement. In just the first 100 days, reducing the communication requirement to 
times of deployment, instrument calibration, and experimental data gathering could have reduced the total ground 
station cost for the entire mission by 40%. 

2.2 Cost of Transporting Data between the Ground Stations and Control Center 

The ground network between the ground stations and the control center was another cost which was underestimated 
during the preliminary mission design phase. Further, the cost of the network between the various labs and 
spacecraft Integration & Test (I&T) facilities was not in any of the early budget calculations. In the NASA era of 
full cost accounting for all services, these network costs will “nickel & dime” a project to death. 

To reduce the transmission cost from the ground stations to the control center, the Nexus concept was to decode 
science data at the ground site before transmission to the control center. This reduced the total bandwidth needed. 
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Also, the use of CCSDS virtual channel assignments allowed Nexus to only transmit critical data in real-time to the 
control center. Remaining data would be transmitted as bandwidth became available. 

One item still to be explored is to use the existing, open Internet to transmit non-critical data. Using the open 
Internet has many advantages in trying to meet the low cost objectives. Encryption, digital signatures, and other 
data security measures can be used to protect proprietary data. 

2.3 Cost Savings via Ground Automation 

A Nexus requirement for ground system automation did not result in significant savings. The broadly stated 
requirement was at odds with the objectives of low cost development and low cost operations. At the program level 
of Nexus, contact time cost dwarfed the cost trade between automation development and off-shift operations 
personnel. 

Automation to collect and store telemetry at the ground station would have been more cost effective than personnel 
reductions or unattended operations within the Nexus control center. Automation of the Nexus control center 
required a longer mission lifetime or cost sharing across multiple programs to be affordable. 
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3. Selection of a Real-Time Telemetry and Command System 

A low cost, low risk ground system was needed to balance the costs and risks of the Nexus demonstration 
spacecraft. A real-time T&C processing component was central to the ground system design. This section provides 
details on the trade study we conducted to select an existing T&C component. 

The real-time T&C analysis was divided into three segments: 

• Reuse of the Nexus real-time T&C system for NGST 

• Feasibility of using a “Finite State-Based Modeling” product 

• Commercial Off the Shelf (COTS) versus Government Off The Shelf (GOTS) products 

3.1 Reuse of the Nexus real-time T&C system for NGST 

We decided to select the Nexus real-time T&C system separately from the NGST ground system, even though some 
operational concepts were expected to carry over. The Nexus mission’s one year duration is quite short when 
compared to 10-15 years for NGST. Selection of a ground system in 2001 for use in the 2009 NGST mission 
seemed premature. 

3.2 Feasibility of Using a “Finite State-Based Modeling” Product 

As part of new technology research, and doing business in a new way, we proposed using a Finite State Modeling 
(FSM) system for Nexus. It was necessary to consider the advisability of switching basic operation paradigms from 
traditional telemetry to FSM. Initial findings indicated that higher costs would be incurred up front with lower 
maintenance and upgrade costs in the out-years. However, using a FSM system with the required up-front work 
during development and testing was a substantial undertaking and not cost-beneficial for a short mission. We found 
that GSFC had, on three previous occasions, attempted to use FSM as an add-on to operations and it never resulted 
in a reduction in cost. 

3.3 COTS versus GOTS Products 

A third early decision centered on the relative merits of COTS versus packaged GOTS T&C components. The 
spacecraft and flight software development groups at GSFC tasked with building the spacecraft were most familiar 
with locally developed GOTS T&C components, some of which were also available in COTS form. This familiarity 
was expected to translate directly into lower development costs due to process/tool reuse and lower spacecraft 
integration and test risks. A specific issue in the GOTS analysis was whether to select the HST Vision 2000 
Command and Control System (CCS) solution as the T&C component. The STScI personnel we expected to 
operate Nexus already had operational familiarity with the CCS system. COTS solutions offered development 
independence from other GSFC missions, less development effort using a packaged product, and more operations 
features (particularly in the area of automation for lights-dim or lights-out operation). It soon became clear that the 
COTS versus GOTS issue was less important than the complexity and capability of the various candidate T&C 
components, and the relative development cost. These became the ultimate criteria for evaluation. 

3.3.1 COTS versus GOTS Phase One Evaluation 

In Phase One of the process, we identified candidate products and evaluated them on key criteria related to 
capability, cost, performance, and risk. The evaluation data were collected through mission manager interviews 
with NASA/GSFC, JHU/APL, the USAF, and through COTS vendor interviews as well as COTS demonstrations at 
vendor sites. 
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The products selected for Phase One evaluation were: 


Altairis MCS (FSM, COTS) 
ASIST (GOTS) 

HST Vision 2000 CCS (GOTS) 
ECLIPSE (COTS) 

EPOCH 2000 (COTS) 

ITOS (GOTS) 

SCL (FSM, COTS) 


Altair Aerospace Corporation 
NASA/GSFC Code 584 
NASA/GSFC Code 442 
Raytheon Corporation 
Integral Systems Incorporated 
NASA/GSFC Code 584 
Interface and Control Systems 


Four of these products were eliminated here: two were based on FSM, and cost and complexity eliminated another 
two. ASIST, EPOCH 2000, and ITOS were selected for detailed evaluation in Phase Two. 


3.3.2 COTS versus GOTS Phase Two Evaluation 


Experience gained during Phase One interviews was used to focus the baseline real-time T&C requirements and 
operations concept. In Phase Two evaluation, we sought answers to the following questions: 

1 . Will each product, as delivered, meet basic mission requirements? These were the following: 

Provides necessary functional capabilities 

Supports Development, I&T and Operations mission phases 

Supports operational concepts including Shuttle launch, L2 orbit, and automation for lights-dim 
operations 

Supports desired PC-based H/W platform 

Compatible with planned DSN/USN Ground Station environment including CCSDS compliance 
Enables operator productivity with an intuitive, user-friendly interface and available tools 
Is mature; at least one previous mission 
Is stable, according to the experience of other users 

Is maintainable (based on open source or responsive vendor), has limited dependencies on other 
COTS, and has well-defined APIs for future expansion 
Is affordable in cost/benefit terms, with an upper limit on cost 

2. What is the estimated cost and effort needed to modify each product to meet any of these requirements that 
it currently fails to meet? 

3. What additional features does each product offer that might do any of the following? 

Increase ground system usability 
Decrease risk 
Decrease cost 

Phase Two evaluation was performed using specific criteria to support the baseline mission in detail. Phase Two 
products were installed at GSFC for an extensive hands-on, side-by-side comparison. Each vendor provided 
integration support and responded to evaluator questions, and the results for each product were discussed with the 
vendor to minimize misunderstandings. 

We found that each of the products (ASIST, EPOCH 2000 and ITOS) could adequately support basic mission 
requirements. Each product required a minimal configuration effort and only a small enhancement effort to meet all 
of the baseline requirements. We were searching for real-time T&C components that supported Nexus “right out of 
the box,” and found several to choose from. The development of the operations concept in parallel with the T&C 
component evaluation allowed us to focus on interfaces and broad capabilities. Side-by-side operation of the 


7 



Selection of the Ground Segment for the 
Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) 

competing products allowed direct comparisons of capabilities despite their differing design approaches. Had we 
entered the evaluation and selection process with less flexibility, we would likely have required significant 
additional functionality in each product, resulting in higher software development costs. 

We would like to thank NASA Code 584 and Integral Systems Incorporated for their support of our side-by-side 
evaluation. 

3.4 Use of the Same Real-Time T&C System from Component Development through Operations 

One of the cost-saving concepts for the Nexus ground system was to use the same real-time T&C system beginning 
with component development and continuing through flight operations. A similar approach has been used on the 
ACE, NEAR, and TIMED missions with encouraging success. With the use of the same T&C system, lifecycle 
operations costs can be reduced by combining I&T and flight operations team responsibilities into a single, 
integrated team. 

Common functions performed by this team include: 

• Developing and validating the databases of spacecraft telemetry and commands 

• Developing procedures to be used during the mission 

• Building display pages for the mission 

• Configuration Management of the various items 

• Training of the Flight and Experimenter teams 

Using a common database for a seamless transition from the start of flight software development through the end of 
the mission would provide additional cost-saving. Such a database would reduce system tool learning curves and 
eliminate the repetition of providing the end database product. For NGST, the common database approach would 
also provide additional benefits in support of multiple, geographically distributed institutions. 

Reuse of the real-time T&C system fit well in the Nexus mission schedule since the time planned for operations was 
relatively short. NGST will be a much longer mission than Nexus. The historic lifecycles of operating systems, 
computer hardware, and software are far shorter than the lifecycle of the NGST l&T and mission phases. Our 
challenge is to find components that can be translated easily so that NGST is not tied to using 1990 technology in 
2010. 


4. Development Facilities, Testing Labs and Simulations Support 

The development and testing of the Nexus spacecraft required the coordinated efforts of a large number of engineers 
working in a number of facilities (see Figure 3). As the spacecraft schedule was developed, we were surprised to 
count 14 separate facilities that required a real-time T&C ground system. Additional integration and environmental 
test facilities were identified that required real-time T&C ground systems but could re-use systems which had 
already been procured for other facilities. This distributed approach to development and testing made the number of 
test facilities, and the resulting number of real-time T&C ground systems they required, an important cost issue. 
The overall cost to procure the real-time T&C ground systems was dominated by the number of facilities receiving 
such systems, rather than the relative cost of each instance of the three candidates. The total cost to procure the 
systems to support I&T was far larger than the cost to procure the systems to support flight operations. 

The proliferation of separate testing facilities confers some benefits in making the mission schedule less dependent 
on critical hardware or facilities. Additional facilities can also increase costs due to the need for additional 
simulations and test equipment and the potential for unnecessary test duplication. Fewer shared testing facilities 
would reduce ground system procurement costs. Shared testing facilities also have the potential to encourage 
increased collaboration among spacecraft developers. 
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Another major cost issue for testing facilities is represented by the simulators needed to adequately test spacecraft 
components before launch. We found that the fidelity of simulators could be addressed in terms of cost versus 
simulator fidelity, but the tradeoff between simulator fidelity and program level risk was poorly understood. 


I Both H/W and 
i Ground S/W 
▼ migrate 

I Only Flight 
H/W migrates 

▼ 


I Flight S/W 

(Development & 
Maintenance) 


C&DH FSW 
(D&M) 


IPE FSW 
(D&M) 


AGS FSW 


(D&M) 

PSE FSW 


(D&M) 


Both H/W and S/W remain 


Integration & Testing 



Both H/W and Ground S/W migrate 



Figure 3. Distribution of Nexus Real-Time T&C System Hardware and Software 
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5. Conclusions: Ground System Cost Factors 

Ground system operations should be considered a key component during mission development. The cost trades 
between spacecraft and ground components, which can decrease the total cost of the entire project, should be 
determined as early in the design phase as possible. 

Significant lessons learned regarding ground station costs are the following: 

■ Ground station cost, contact schedule and length of contact are the most expensive elements in the ground 
segment. 

■ Length of ground station contact time during the various mission phases should be defined as part of a risk 
assessment as well as cost. 

■ Having an operation cost target in the beginning helped us with leverage over the other disciplines. For 
example, the use of the 13-meter antenna made the Command and Data Handling (C&DH) group focus on 
their downlink requirements 

■ The operations scenario for the first 100 days of Nexus (deployment) differed from nominal operations. 
Deployment deserved more extensive analysis with regard to navigation and telescope instruments. An 
example is the Nexus telescope, nominally used to view dim objects, was required during deployment of 
the telescope mirrors to use bright stars for calibration and alignment. This raised competing telescope 
detector requirements. 

■ The open Internet should be considered for use in non-critical data delivery since higher rates drive up 
ground data line requirements. When data are downlinked during the weekend it is often acceptable to 
delay examination until Monday. Nexus required data delivery within 20 minutes of receipt on the ground. 
The true need of data delivery desires should be challenged to assure that real requirements are met. 
Desires that exceed requirements will drive ground network costs dramatically upward. 

Use of the same real-time T&C system to support component development through flight operations is desirable for 
a mission with a short Operations lifecycle such as Nexus. For the Nexus mission we found the following to be 
true: 


■ Many real-time T&C systems available as COTS or GOTS can do the job (this is more of a preference than 
a cost item) 

■ Savings from the use of the same real-time T&C system for component development through flight 
operations can be overshadowed by the costs from the number of labs and facilities. 
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